在数字化转型热潮下，各家企业都想建设中台，那么中台是怎么发展起来的？有哪些类型的中台？中台到底是个啥？本文为你一一解答这些问题。
图片来自 Pexels
2019 年春夏之交，领导（我司 CIO）送了我一本钟华老师的《企业 IT 架构转型之道：阿里巴巴中台战略思想》（该书的读书笔记）。
在阅读之后，我初步地了解所谓的中台战略，但又还是停留在感性层次，只会说出几次消除烟囱，数据孤岛之类的感性的“大话”。而后在 2019 年冬季又订阅了王健老师的《说透中台》专栏想要进行深入学习加以更好地理解，于是有了这个系列的学习总结文章。
在本篇文章里，我将我在这个专栏和一些中台的书籍的内容加以整理，也从众多参考资料中 Copy 了很多图示加以其中，最后给出我绘制的整体的知识总结脑图。不过我决定不按套路来写本文，先给出学习总结中最最精华的部分，给那些只想快速了解中台的人。
但是中台这个东西，现在业界并没有一个完整的标准定义，每个人的经验和视角也不同，因此可能一百个学习者心中会有一百个中台，这里我主要引用我学习的专栏中内容的总结。
一句话概括：“以用户为中心，从战略入手，愿景为指引，用科学有效的方法，步步为营沉淀企业级能力，辅以必要的组织与系统架构调整，方得中台。”
中台为前台而生，专注于为前台赋能，沉淀企业的能力与复用，提升企业的客户响应力。
如果你是企业的 CIO/CTO，信息部总监，那么你可能需要更多关注与企业架构方法（如 TOGAF）、组织架构、事件风暴、愿景规划等等，因为你要做是中台最基本的工作：数字化全景规划。
如果你是架构师，那么你可能需要更多关注中台团队能力建设、DDD 工作坊、精益产品研发流程、敏捷开发流程等等。
如果你是开发者，那么你需要更多关注微服务架构风格、DDD 领域驱动设计、DevOps、敏捷开发等等。
中台是一个偏业务层面的概念，技术上并没有带来什么新的东西。其实，只要你了解微服务、DDD、DevOps、敏捷开发等就足以做一个合格的中台开发者了。
当然，做中台不一定就需要微服务架构，而别人使用微服务架构可能也不一定建设的是中台。
OK，到此为止，以上五个问题就是我学习的资料里面的精华内容了，如果你觉得不够，那么请继续往下看。
先剧透一下，由于中台是个偏业务层面的概念，因此想要了解具体实现技术的童鞋，走错片场了，可以离场了，本学习总结 Cover 不到你的需求。
了解一个东西，需要首先了解它的发展史，又或者说看看它的过去，这里我们就先看看中台的发展历程：2008~2015：孕育期。2008 年阿里巴巴开始战略调整，重复建设与烟囱架构问题出现；阿里共享事业部诞生，前台系统中的公共部分开始平台化改造。
2015：中台战略诞生。马云带领阿里高官走访芬兰游戏公司 Supercell 受到触动；阿里巴巴正式启动中台战略“大中台、小前台”。
2017：横空出世。互联网大厂集体发声，各自分享中台建设经验。
2018：全面爆发。互联网大厂集体宣布组织架构调整，正式将中台推上舞台。
2019：迷雾仍存。中台的热度越发高涨，跟进企业越来越多，但问题不降反增。
不管是身处浪潮一线的互联网大厂，还是传统行业的转型企业，似乎在 2020 年都有建设一个中台的需求（至少都在采取行动或开始学习），不管真的想进行能力沉淀复用还是追概念来个弯道超车，中台正在被越来越多的人熟知。
不得不说，BAT 等大厂的样板和标杆效应非常强！先行者们的建设效果让人羡慕不已！
消费互联网进入中后期，产业互联网开始火爆！而云和中台是互联网企业进入传统行业的非常好的切入点。
这些互联网企业依靠自身储备帮助传统企业数字化转型，而在传统企业的转型过程中，中台是很好的抓手和利器！
刚好这几年匹配上传统行业从系统化向平台化转型的时间节点，企业信息化的问题凸显，如烟囱林立、数据孤岛等等；似乎家家企业都觉得有做中台的需求和痛点，并开始了中台规划和建设。
近年来，不确定性和不可预测性不断冲击各个行业的企业，企业的高层管理者们焦虑倍增。
在看到互联网大厂的样板效应之后，想要模仿也将自身企业的能力进行沉淀与复用，用确定性应对不确定性。
这里所谓的确定性，我的理解就是基于核心能力的复用，在面对业务扩张或转型时，不会慌得一批。
因为你知道你可以很快的复用已有能力去开拓新业务并实现转型而不是从零开始，或许你可以认为你企业的用户响应时间是可以确定的，这对传统企业来说的确是一个突围方向！
这里的前台是由各类前台系统组成的前端业务平台，例如官网、公众号、小程序、H5 客户端等；而后台是由后台系统组成的后端支撑平台，例如 ERP、CRM、WMS 等核心系统。
经历过企业级项目开发的人都知道，大型企业的后台是所谓的企业“遗留系统”的重灾区。
前台需要快速响应前端用户的需求，要求越快越好，但是后台是相对稳定的企业核心后端资源，陈旧而复杂，因此出现了“前台+后台”的“齿轮失衡”问题凸显！
在互联网时代，用户才是商业战场的中心，互联网公司们纷纷借助平台化，以实现快速响应用户的需求。
无论各行各业，企业的核心能力都是：用户响应力！因此，传统企业也需要进行平台化转型。
这里的平台化，主要侧重于 IT 能力的去重，属于 Cost Saving（降低成本）的策略。
在平台化的过程中，平台不断对于自身治理演进、逐渐拥抱业务的过程就是中台化的过程，大家会发现需要一个中台。
这个中台主要关注为前台业务赋能，要真正为前台而生，实现 Value Add（放大价值），Cost Saving+Value Add 即我们通常所说的降本增效。
例如，阿里巴巴的业务中台其实就是由阿里早先的交易平台演进而来，最终实现业务能力的灵活复用，所以这里才说中台化是平台化的下一步。这里的前台是由各类前台系统组成的前端业务平台，例如官网、公众号、小程序、H5 客户端等；而后台是由后台系统组成的后端支撑平台，例如 ERP、CRM、WMS 等核心系统。
刚刚说到，中台出现的背景主要就在于：“前台+后台”的“齿轮失衡”问题凸显。
因此，中台其实就是架在前台与后台之间的一组“变速齿轮”，起到的作用类似于桥梁及润滑剂，其价值主要在于：将后台资源顺滑地通过前台流向用户，提高企业用户响应力。
虽然中台有这么大的价值，但是就跟技术架构一样，每引入一项新的东西都会增加现有的复杂度。
你要享受微服务架构风格的牛逼和潇洒，也得承受微服务带来的各种复杂度，无论是集成、部署还是运维，都会增加你的负担，中台亦是如此。
中台需要强力的战略执行力、必要的组织架构调整、合格的技术团队建设等等，都是需要很大成本的。
目前来说，主流的中台分类（即大家广为谈论的）有两个：
主要是指通过将不同业务线解决相同问题域的解决方案进行抽象和封装，通过配置化、插件化、服务化等机制兼顾支撑不同业务线的特性需求。
大部分谈论中台的人，应该都是谈的业务中台，因为不论什么中台，最终都是为业务服务，赋能前台，提高企业的用户响应力的。
数据中台也是个火爆的概念，在 DT 时代，企业逐渐都深刻意识到数据的价值。那么，它与业务中台的联系在什么地方？
可以这样理解，业务中台在产生数据，数据中台是做数据的二次加工，并将加工结果再服务于业务，为业务进行数据和智能的赋能。
当然，在不同的人的眼中，看到的中台都是不同的类型，可能张三认为中台是技术中台，应该是微服务、DevOps 平台、容器云平台这一套组合。而李四可能认为中台是组织中台，应该是企业内部资源调度中心和内部创新孵化组织等。
因此，每个人的视角和立场不同，都会对中台有不同的理解，其他的被大厂推广的类似中台还有研发中台、安全中台等。
面对种类繁多的中台，我还是比较认可网易云的观点“所有的中台都是业务中台”，而其他的中台其实都是一种广义上的业务中台，被称之为中台，就需要具备一定的业务属性，最终都要为业务服务。
可能看了这么多，我们还是不能给中台下个定义，不过这里我真的很认同王健老师的这句话“中台，即企业级能力复用平台！”
所谓企业级，主要是指中台处理的问题范围在企业级别，即包含多条业务线或服务多个前台产品（团队），且建设中台一定要跳出单条业务线、站在企业整体视角来审视业务全景。
所谓能力，主要是指中台主要承载的对象，每家企业的核心能力都不同，要找到差异化竞争力。
所谓复用，即中台的核心价值，它的可复用及易复用的特性能够实现更多地对前台业务的支撑。
所谓平台，即中台的主要形式，它通过对于更细粒度能力的识别与平台化沉淀，实现企业能力的柔性复用。
所谓“遇事不决看愿景”，即建设中台为了解决什么问题？对于企业和业务又有什么价值？
这是需要提前想清楚的，并且这个愿景是需要所有角色都要明确并且达成一致的。否则，会在后续建设过程中迷失方向，偏离初心。
一般采用投融资模式，即在建设前期就由企业本身的战略储备资源投资建设，服务稳定之后，对前台产生稳定价值之后，再逐渐从前台收取一定的资源。
因此，这种模式比较适合适合解决企业长期战略目标（比如业务转型，这也是大部分企业正在做的事儿）。
这种模式的优点在于中台团队在建设初期有更多的自主权，有利于实现中台愿景，但是需要企业有较雄厚的战略资源支持和更大的战略决心才能推广下去。
这个问题也是需要在建设中台之前就要思考如何验证和度量的，像阿里巴巴就将其中台的考核设计为：40% 稳定性+25% 业务创新+20% 业务接入量+15% 客户满意度。
验证指标的设计是一个复杂的过程，也是需要不断演进，需结合愿景、投资模式等综合设计。
在长期的咨询指导和架构实践的过程中，ThoughtWorks 形成了一套完整的中台建设方法论模型：D4 模型。
之所以称之为 D4（也与 Diss 这个单词有关），主要是 ThoughtWorks 把中台从整体规划到落地交付的过程划分了四个不同的阶段，包含了两次发散与收敛的过程。
这个模型的主要受众应该是 CIO、信息部总监、业务架构师等等。
在这一阶段，主要是做企业战略的分解及现状的调研，目的是建立一个对企业和行业的全面视野，尽量发散收集大量信息。
由外到内：行业与竞争对手分析，目的是知己知彼百战百胜！工具：SWOT/商业模式画布等。
由上而下：企业战略分解，目的是找到中台建设的大方向！工具：精益价值树等。
由下而上：现状调研与分析，目的是了解现状和历史，收集汇总痛点！工具：用户旅程+服务蓝图等。
这一阶段，主要是对 Discovery 阶段收集的信息进行分析和收敛，最终形成企业的数字化全景规划。
这个过程中，需要对跨业务线的业务梳理进行重合度分析、探索企业核心问题域（使用 DDD）以及形成具体的实施路径规划。
等到这个过程结束，其实就帮助回答了两个问题：一是到底需不需要中台？二是需要哪些中台？
可以采用的工具：TOGAF+DDD 工作坊+事件风暴等。
平台型企业架构设计方法论（From ThoughtWorks）
这一阶段，已经得知需要建设一个中台，就可以开始规划和设计了，主要会确定以下几个事，也是一个发散的过程，尽可能地多输出。
首先，确定中台产品愿景，确定业务梳理范围（收敛聚焦区域）。其次，细粒度地进行业务梳理，回到业务本身，从问题域出发，以用户为中心，进行用户体验设计和业务服务蓝图的梳理，比如采用用户体验旅程图+服务蓝图等。
最后，确定要实施的最小可用品 MVP，来一个端到端的纵向切分的薄片进行验证。
在此阶段，也可以开始制定迭代计划及接入计划，合理的计划能够帮助规避一些风险。
此外，还可以定义验证指标，如上面提到的如阿里巴巴就将其中台的考核设计为：40% 稳定性+25% 业务创新+20% 业务接入量+15% 客户满意度。
这一阶段，已经拿到了一个作为切入点的中台场景，并且经过 MVP 进行了快速验证，如果能够通过企业内部的立项审核和流程，就可以开始一个正式的中台项目建设开发了。
第二步：结合精益思想与敏捷实践进行中台的具体研发过程。精益思想的核心目标是消除浪费，创造价值，整个研发流程其实也是一个复杂的系统性工程。
这一过程，也就是我们普通开发人员所主要参与和关注的过程。是不是很纳闷，这么长的文字，终于等到我们普通开发者出场了，TMD 戏太长了！
不过，这部分童鞋可能真的会失望了，因为正如我在最开始的时候所说，中台并没有带来什么技术上的新东西，它更多是偏向与业务层面的概念。
参与开发中台，我们要使用的其实还是微服务、DDD、DevOps、云原生这一套技术，对，还是这些东西，但是，你又真的学习了多少？
精益产品研发流程（From ThoughtWorks）
第三步：中台的运营、治理与演进。可以采用三层 SLA 用户划分机制，优先支持高层用户的响应，构建不同层次的运营体系，从而实现资源的合理调配。
二者解决的是不同的问题，也处于不同的抽象层次。中台解决的是业务领域复用的问题，微服务解决的是技术领域的"组件编译时依赖"造成的问题。
业务中台不一定是微服务架构的，微服务架构也不一定是为了能力复用的问题。
技术中台强调从全局业务视角的出发，中间件则主要从技术去重的视角出发。
因为近年来经济行情的压力，导致越来越多的企业开始寻求转型并开始了自己的数字化战略。
因为自己的公司正在做数字化转型，所以我才会参与其中并有动力去了解中台的概念。
看来看去，读来读去，不管是中台还是 X 台，本质都是企业想要增强确定性来应对行情的不确定性所做的一个措施而已。
为了让企业的管理者能够不慌得一批，中台是被强行推着上了舞台中央，并且四面八方都给了它闪光灯。
对于我们普通开发者而言，对于新概念应该保持好奇，而不是一开始就去盲目地否定，先接纳再结合自身的情况做判断。希望我的学习总结能为你解开一丢丢的疑惑我就心满意足。
参考资料：（本学习总结引用了大量以下文章的内容及图片，对下面作者表示感谢）王健，极客时间《说透中台》专栏
葛晓玲，《不做中台会死吗？企业真的需要一个中台吗？》
钟华，《企业IT架构转型之道：阿里巴巴中台战略思想与实践》
张善友，《基于 Kubernetes 建设.NET Core 技术中台》
不止思考，《要不要赶个时髦，去建设一个中台》
无涯，《大道至简，中台是啥》
沙漠之鹰，《大型科技企业架构：中台模式的爱与恨》
陈春花，《解读数字化战略与新产业时代》
【有报告】重磅展示银行业 MGR 应用调研报告
【有细节】架构原理、冲突检测机制、事务处理流程、高扩展性
【等你来】3 月 18 日晚 8:00（长按识别上方二维码立即报名）
作者：Edison Zhou
编辑：陶家龙
出处：转载自微信公众号恰童鞋骚年（ID：edc-saonian）